@twelch and @mfedderly, can we have a time out before merging this change?

Looking at last-checks many of the tests seem to overlap with monorepo linting. Additionally they depend on the built JS files in dist/ which i'm hoping we can avoid generating for local and CI builds.

There may be benefits to keeping them in a separate step for the time being.

@smallsaucepan yeah we can definitely hold this one, I'm curious how you will avoid building on CI and still get typescript type checking done. The weird testing format in @turf/turf has always been somewhat overlapping with the capabilities of monorepolint, it predated when I brought in monorepolint to get things standardized across all of the packages years ago and never fully reconciled it all.

Thanks for that.

how you will avoid building on CI and still get typescript type checking done

The test:types target in each package runs a tsc --noEmit which should uncover any compile time TS errors. We can run that directly on the types.ts or index.ts file in each directory.

To be clear I'm not deep enough in the build workings to be able to contribute much to the discussion yet other than learn. I've been trying to only approve smaller build related PRs that don't seem to affect the larger deliberation you've both been having. Just to keep things incrementally improving. If this PR is more than that I apologize.

test:types target

That's actually really cool! My only two flags would be making sure that test:types exists everywhere, and that it really does trigger errors on build errors for itself and any packages it depends on if we need that behavior (I worry about something like skipLibCheck causing an issue).

@mfedderly,

1. making sure that test:types exists everywhere
2. it really does trigger errors on build errors for itself and any packages it depends on

Done, and done. Check out PR #2702